It's hard for me to see why in this module we have to switch to operations on ptrs. It causes some uncomfortable integrations into higher layer applications: startWaku(addr waku) is quite a bit less intuitive than waku.startWaku(). My assumption is that this is necessary for the thread management in the bindings? However, wouldn't it be better to wrap this into another ptr operation layer specifically (and only) for the bindings? May be missing some fundamental limitation here.

Thanks for the comment @jm-clius ! 🙌

I agree that it becomes more awkward to use with startWaku(addr waku)

Let me elaborate more on why this is needed:

• We should make the startWaku proc async because the waitFor statement should be only invoked from the highest level to avoid deadlocks. i.e. the waitFor should only be invoked from within the wakunode2 code or highest level of libwaku.

  It is not correct to have a waitFor as we had before this PR. See:
  

  nwaku/waku/factory/app.nim

  Lines 177 to 179 in 853ec18

  	proc startApp*(app: var App): AppResult[void] =
  	let nodeRes = catch:
  	(waitFor startNode(app.node, app.conf, app.dynamicBootstrapNodes))

• The startWaku (formerly known as startApp) changes the state of the given parameter, waku, but we cannot longer pass a var parameter because the startWaku should be async (commented in the previous point) and it doesn't compile ( <<cannot be captured as it would violate memory safety>> .)

• Given that we cannot use var, the only way to allow changing the state of a variable in an async proc, is by using ptr type, which is considered unsafe but in our case we can make sure that the passed Waku instance has longer lifetime than the call of startApp and it won't crash because of incorrect address being used inside the startApp.

Nevertheless, there might be a more elegant approach ( cc @arnetheduck :)